查看原文
其他

一条查询SQL是如何执行的

良许Linux 2024-04-16


前言

日常开发中,我们经常需要写查询SQL。但是,大家知道一条查询SQL在mysql内部是如何执行的嘛?比如这条简单的SQL;

select * from test_db.user_info_tab where user_id =123;

我们知道在mySQL客户端,输入一条查询SQL,然后看到返回查询的结果。这条查询语句在 MySQL 内部到底是如何执行的呢?本文跟大家探讨一下哈,我们先来看下MySQL基本架构~

MySQL 基本架构

总体来说,MySQL大体分为两部分,分别是Server 层和存储引擎层

Server 层

它包括连接器、查询缓存、分析器、优化器、执行器等。比如存储过程,触发器,视图都是在这一层实现的。

  • 连接器(Connection Manager):负责处理客户端与服务器之间的连接。它接受来自客户端的请求,并进行身份验证和权限检查,建立和管理连接。
  • 查询缓存(Query Cache):在旧版 MySQL 中有,但在较新的版本中已不推荐使用。它能够缓存查询和对应的结果,以提高查询性能。然而,在高并发和大型数据库中,它反而可能成为性能瓶颈,因为它在某些情况下会引起锁和不必要的开销。
  • 分析器(Parser):负责分析 SQL 查询语句,验证其语法和语义,确保查询的正确性。它将 SQL 语句转换成内部数据结构供优化器和执行器使用。
  • 优化器(Optimizer):接收来自分析器的查询请求,并决定如何最有效地执行查询。优化器的目标是找到最佳的执行路径,选择合适的索引、连接顺序和访问方法,以提高查询性能。
  • 执行器(Executor):负责执行优化器生成的执行计划,获取存储引擎返回的数据,并处理客户端请求。它与存储引擎交互,执行查询并返回结果给用户。

存储引擎层: 它负责数据的存储和提取。Mysql支持InnoDB、MyISAM、Memory 等多个存储引擎。我们日常开发中,一般用的存储引擎就是InnoDB。从 MySQL 5.5 版本开始,InnoDB 就成为了默认的存储引擎。

介绍完MySQL基本架构,带大家看一下,每个组件,一条查询SQL主要做什么事~~

连接器

我们要执行查询SQL,一般在MySQL客户端, 需要输入连接命令,连接到MySQL服务端。在MySQL服务端,就是连接器负责跟你的客户端建立连接、获取权限、维持和管理连接

连接命令如下:

mysql -h(ip地址) -P(端口) -u(用户名) -p

输入完连接命令之后,我们接着输入正确的密码,经过经典的TCP握手之后,就可以成功连接到MySQL服务器啦,如下:

C:\MySQL\MySQL Server 8.0\bin>mysql -h 127.0.0.1 -P 3306 -u root -p
Enter password: ******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 50
Server version: 8.0.31 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

如果输入密码错误,则会收到一个 Access denied的错误信息,如下:

C:\Program Files\MySQL\MySQL Server 8.0\bin>mysql -h 127.0.0.1 -P 3306 -u root -p
Enter password: *****
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

连接成功之后,大家就可以直接输入查询SQL,就可以看到结果啦。

mysql> select * from test_db.user_info_tab where user_id =123;
+---------+----------------+------+------+--------+---------+--------------------------+
| id      | user_name      | age  | city | status | user_id | password                 |
+---------+----------------+------+------+--------+---------+--------------------------+
| 1570091 | 捡田螺的小男孩 |   28 | 深圳 | 活跃   |     123 | 523da7ne+yndc5nb1zWWlA== |
+---------+----------------+------+------+--------+---------+--------------------------+
1 row in set (0.01 sec)

大家注意一下哈,如果连接成功后,没有后续的输入查询SQL等其他操作。这时候,这个连接是空闲的哈,可以用show processlist查看。

查询缓存

老版本的MySQL中,连接成功后,我们执行查询SQL,会先执行查询缓存

也就是说MySQL接受到一个查询SQL请求时,会先去查询缓存看看,如果缓存有这条SQL的查询结果,会直接返回。如果查询缓存没有,就继续往下执行,执行完之后,把结果写入缓存。其中,这个查询缓存是key-value的结果,你可以把它理解为一个map吧,其中key就是这个查询SQL,value则是这个查询的结果。

同时,如果你查询的表进行更新的时候,会清空缓存的。一个表更新比较频繁的话,使用查询缓存命中率会很低,你刚查完放到缓存,更新SQL又清空了,就很不划算。有些时候,一些静态配置表,很少更新的,才建议使用查询缓存。其他更新频繁的表,则不建议使用查询缓存,你可以通过这个参数query_cache_type 设值是否走查询缓存。

其实,MySQL 比较新的版本,如8.0 已经废弃了查询缓存,并且相应的参数 query_cache_type 也不再存在。因为在高并发和大型数据库环境下,查询缓存可能导致性能问题,并且在实际测试中发现,禁用查询缓存可能会提高整体性能和可伸缩性。

分析器

如果查询SQL没有命中查询缓存的话,继续往下执行,就到分析器上场了。它负责分析 SQL 查询语句,验证其语法和语义,确保查询的正确性

你扔个SQL给MySQL服务器,它肯定需要先解析,才知道这个SQL是做什么的,对吧。它会派出分析器,先做词法分析。你提交过来的查询SQL是由很多个字符创和空格组成的,MySQL会先解析出这些字符串表示什么意思。

select * from test_db.user_info_tab where user_id =123;

它先把关键字select解析出来,然后把user_info_tab解析成表,user_id解析成列名。做完词法分析之后,开始做语法分析。语法分析主要就是判断,你的SQL是否满足MYSQL的语法。

如果你的SQL写错了,语法分析就会报错误提示: ERROR 1064 (42000): You have an error in your SQL syntax;

mysql> select * rom test_db.user_info_tab where user_id =123;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'rom test_db.user_info_tab where user_id =123' at line 1

平时大家看到这个错误的时候,只需要,关注关键词 syntax to use near 就可以快速知道哪里写错啦。比如这个例子,就是我的from写错了,少了f

优化器

经过分析器之后,MySQL已经知道需要做什么了。但是在经过执行器之前,还会先经过优化器。优化器做的事情就是,怎么去做才是最好的。对于一条查询SQL来说就是:怎么去查是最佳效率的。

比如这个查询SQL:

select * from test_db.user_info_tab where user_id =123 and user_name='田螺';

其中,在user_info_tab表中,user_id为索引字段,user_name也是索引字段。

这条SQL执行的时候,可能使用索引user_id,也可能使用使用user_name。选择不同的索引,执行效率是不一样的。具体怎么选择,就是优化器所做的事情。

大家是否还记得explain。我们使用它加在我们查询的SQL,就可以帮助了解优化器在执行查询时,选择的执行计划和相应的优化策略。

经过优化器之后,就来到了执行器阶段。也就是真正执行查询SQL了。

执行器

select * from test_db.user_info_tab where user_id =123 ;

在要开始执行时候,会判断一下,该用户是否对这个SQL有查询的权限,如果没有,则会报权限错误。如果有权限的时候,打开表直接执行。执行的过程,其实类似于执行调用引擎提供的接口

我们现在假设user_id不是索引字段,我们使用的是InnoDb存储引擎,这个查询SQL执行过程就是这样:

  1. 调用InnoDb存储引擎提供的接口,获取user_info_tab表的第一行
  2. 判断user_id是不是为123,如果不是,跳过这一行。如果是,把这一行放到结果集。
  3. 调用InnoDb存储引擎提供的接口,获取user_info_tab表的下一行
  4. 判断user_id是不是为123,如果不是,跳过这一行。如果是,把这一行放到结果集。
  5. 重复3、4步骤,一直扫描完user_info_tab表的所有行。最后把结果集返回客户端。

聊到这里,其实一条查询SQL的执行过程,已经讲完啦,是不是很简单呀~~

最近很多小伙伴找我要一些程序员必备资料,于是我翻出了压箱底的宝藏,免费分享给大家!


扫描海报二维码免费获取。



继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存